This is Chapter 14. If you want to go back to the beginning, you can find it here: Chapter 1. Or go back to Chapter 13.
Video 14: Introducing the MDriven Server
To make your experience smooth, we set the main tags mentioned in the video to the right bar menu of this mini-player. Choose an interesting subtitle on the list and immediately get to the exact theme navigation item place in the video. Now you can pick any topic to be instructed on without watching the whole video.
Chapter 14: Installation and Use of the MDriven Server
In this chapter, we'll go over the installation and initial use of the MDrivenServer for development.
- The MDrivenServer makes your application enterprise-grade and allows you to connect to your own database with a connection string.
- The MDrivenServer understands your model and offloads you of all the hassle of keeping your DB-schema compatible with your system needs.
407. Press the play button and start the Local Turnkey Prototyper. Your webapplication will start running.
408. Find the XML file that stores the data in the box to the right of “Use XML file for data”. Search for the file location on your computer.
409. Open the XML file with Notepad and take a look to see that you recognize it.
410. Open the Cloud-connection dialog from the toolbar.
411. Download the latest for Local servers.
412. Add a server-pair - Server1
413. Refresh the install to Server1
414. Follow the file path to open the install folder. Make sure you see the files.
415. Add another server-pair: Server2
416. Refresh the install for Server2
417. Start Server1. Click on Start Servers.
418. Ensure you see 2 command windows - one for the MDrivenServer and one for the TurnkeyServer.
419. Press Start Servers again to verify that the server pair re-starts.
420. Start Server2. Ensure you see 2 new cmd (command) windows.
421. Pick Server1's MDrivenServer as the active MDrivenServer by first switching the tab to "Active MDriven Server".
422. Type in the address of the MDrivenServer - http://localhost:5000 - also, type user a and password 123456
423. Press Check Server status. Verify that it says "Never started, No current version".
424. Head back to the "Local Servers" tab and use the "Use Above MDrivenServer" button to choose the Active MDriven Server.
425. Try to start the Server2 pair. Choose it as Active and check its Server status.
426. Stop (close) the cmd windows for the Server2 pair (Ports 5002 and 5003). Now click on "Check server status" again.
427. Verify you get the expected timeout due to the server address being closed.
428. Switch back to the "Local servers" tab, pick Server1, and click Use Above MDrivenServer.
429. Verify that the green indicator shows http://localhost:5000
430. Press the "Upload model" button. This will upload your current model to the active MDrivenServer.
431. Press the "Check Server Status" button. If you do it too quickly after the upload, you will not get a full result – but, if you do so, click again.
432. Verify that the returned result states that the database was created for us.
433. Also, press "Update ServerSide jobs" for good measure. Since we have not covered or defined server-side jobs yet, the result will be nothing.
434. Go to the MDrivenServer Web-UI by entering http://localhost:5000 in a browser.
435. Login with a and 123456 (the weak password is okay since this server is on localhost and can only be reached by users allowed on your machine).
436. Go to Running and choose Model. You should see an uploaded model.
437. Go to Running and select Data in A0. You will see all the classes you added to your model. Choose Car and click on Search - verify that there is no data.
438. Migrate data into the DB (database). Go back to the Designer. Start by pressing “play” and wait for the System prototyper to pop up.
439. Start the system with XML persistence. Click on “Start system”.
440. Press Migrate, then select the green button inside the Migrate window. In the popup window, save the data to migrateToDB.xml
441. Close the Migrate dialog, switch to the MDrivenServer persistence, and click on “Start system”. Press the Migrate button again.
442. Now click on the pink button, choose the migrateToDB.xml file and click on “Open”. Note the number of objects created and relations set. Select the yellow button to save the data.
443. Head back to the MDrivenServer web UI(http), click on Running, then Data in A0 select Car, then Search. Verify that you now have the data.
444. Double-click one of the Cars in the search result. Verify that you get an AutoForm displaying the data.
445. Click the "Open" behind the BrandOfCar single-link and verify that you get the Brand AutoForm, showing the data - including the image of the brand.
446. In the Designer, click on the "Play" button in the LocalTurnkeyPrototyper tab. In the System prototyper, switch the "Data" from "Use XML file for data" to "Use MDriven Server".
447. Press restart to apply the changed settings to the Turnkey-prototyper.
448. In the spawned web page, you may now see an error: "The Singleton class SysSingleton has multiple instances".
449. If you see this error, use the following steps to fix it. If you do not have the error, follow the steps but avoid any data.
450. The error is an effect of the migration migrated in one instance of SysSingleton, and the system already had instances of SysSingleton - totaling to 2. The Singleton concept does, however, force us to have only 1 object. To fix it, we must reach in and delete one of the instances of the SysSingleton, leaving only 1, or 0, because if 0, the oclSingleton operator will recreate it for us when we first ask for it.
451. To remove the extra SysSingleton: go to "Play"/MDrivenServer persistence/ Start the system - click the debugger. Find the SysSingleton in the Classes picker, click "Select 50" – Execute (F5) and see the 2 objects. Press “Seeker” and Search. Select one of the objects and click "Delete Selected". Head back to the main debugger form. Click Save.
452. Now go back to the failed web page and press F5 to refresh the page. Verify that the app now works as before.
453. We are now running against a relational database controlled by the MDrivenServer. This means we must change the schema (definition of DB tables and DB columns) in the database whenever we change things in our model. Let’s experiment.
- Start by adding a new class
Class1and head over to the cloud-connection dialog. - Click "Upload Model".
454. Click "Check Server Status". If you get no new feedback, wait 1 second, then press again.
455. Verify that the feedback from the server states that a table for storing objects of Class1 has been added to the database for us.
456. Add a few attributes to Class1, then upload the model again and verify that the MDrivenServer Status says the database schema was changed to accommodate the new attributes.
457. Delete some of the attributes and upload the model again. Verify that the MDrivenServer Status indicates that the MDrivenServer has removed columns from the table.
458. Add an association between Class1 and BrandOfCar, for example. Upload the model and verify that MDrivenServer Status indicates that the MDrivenServer has added columns to store the foreign key - which will hold the primary key of an object- that constitutes the association on the database level.
459. Now delete this experimental Class1, upload the model, and verify that MDrivenServer Status indicates that the MDrivenServer has dropped the table for Class1 and also drops the column for the foreign key in BrandOfCar.
460. To learn more about the MDriven Server, look up MDriven Server on the MDriven Wiki.
461. When you are ready to deploy your application to a wider audience, you will want to run the MDrivenServer and MDrivenTurnkey on a server to which your users have access. This may be a company's internal network or on the internet.
- You can always refer to wiki.mdriven.net to find out how to install the software on either a Microsoft Internet Server or on an Azure web application or run the core servers from Linux-based servers.